Libris Britannia 4/science library(b).zip/science library(b)/INFO/PROGUIDE.ZIP/GUIDE.TXT

Text File | 1990-05-17 | 85KB | 1,695 lines

                              PROGRAMMER'S GUIDE
                     Copyr. 1985, 1989, 1990  Nelson Ford

                               January 1, 1985
                          Major Update: January 1989
                           Continual Updating Since

                          Public (software) Library
                                P.O.Box 35705
                            Houston, TX 77235-5705
                                [phone]
                                      -
                             CompuServe 71355,470


    A limited license is granted to reprint short extracts from this guide
    as long as credit is given and a copy is sent to the address above.
    Individuals may copy this guide for each other as long as no fee is
    charged. No other copying of this guide is permitted in any form without
    the express written consent of the editor, Nelson Ford.

                                     ----

    NOTICE:   ALL INFORMATION, TIPS AND ADVICE IN THIS GUIDE ARE PRESENTED
    TO "GUIDE" YOU INTO AREAS FOR YOU TO RESEARCH AND STUDY IN MORE DETAIL
    ON YOUR OWN. IN NO CASE WILL NELSON FORD OR OTHER CONTRIBUTING WRITERS
    BE LIABLE FOR DAMAGES RESULTING FROM YOUR ACTING UPON INFORMATION THAT
    IS CONTAINED HEREIN. IN PARTICULAR, AN ATTORNEY SHOULD BE CONSULTED ON
    ANY QUESTIONS OF LAW BEFORE FOLLOWING ADVICE CONTAINED HEREIN.




PROGRAMMER'S GUIDE                                                   Contents

                                   CONTENTS

    Forward - Does shareware work?

    Introduction - different marketing approaches.

    Chapter 1 - Marketing Shareware
       getting publicity
       sending out your program
       advertising
       a "pure" shareware marketing strategy
       shareware vs retail-only programs
       - the user's point of view
       - the author's point of view
       do users pay?
       crippled demo's
       pd/shareware distributors
       a sample shareware licensing agreement
       other protective measures
       sample disclaimer of warranty
       selling registered versions through shareware distributors
       selling registered versions through retail distributors

    Chapter 2 - Making Your Program User-Friendly
       on-screen help
       rules for BASIC programmers
       make the program and keys work naturally
       let the user customize
       put things back where you found them

    Chapter 3 - Writing the Documentation
       keeping your files together
       number each release
       multiple documentation files
       formatting, printing the documentation
       contents of the documentation file

    Chapter 4 - The Association of Shareware Professionals ("ASP")
       goals of ASP
       membership criteria
       vendor standards
       meetings on IBMNET

    Chapter 5 - Where to Get Supplies and Services
       telephone: 800#, answering machines, answering services
       disk labels
       blank disks
       disk duplication
       disk mailers & boxes
       credit card processing
       manual publishing

    Appendix A - Letters from Authors
       David M. Berdan, author of File Express
       Edward H. Kidera, author of PC-KEY-DRAW, letters #1 & #2
       Frank A. Bell, author of Newkey

PROGRAMMER'S GUIDE                                                    Forward



FORWARD

The purpose of this guide is to provide tips on marketing and writing programs
that look and work like top-notch professional software. Another purpose is to
get programmers to share their ideas with each other.

This guide is also going to new program authors, so some of the points may seem
obvious or elementary to experienced authors.

The information and opinions in this guide are drawn from several areas of the
author's experience:  as author of a shareware program, Diskcat, which has
been in distribution since September 1983 (and many other shareware programs
since); as head of the Public (Software) Library since 1982, during which time
I have reviewed many thousands of pd/shareware programs; as author of the
column "The Public Library" for the late SOFTALK magazine; and as software
reviewer for other publications.  Information has also been solicited from
shareware authors and users via correspondence and surveys.  The complete text
of the more significant letters is presented in Appendix A.

This file is formmated for printing.  Start the print head just below the top
of the paper and copy the file to the printer from DOS.


DOES SHAREWARE WORK?

Andrew Fluegelman started the formal shareware concept (he trademarked the
name Freeware for it).  Andy did not say that everyone who spent an afternoon
writing a program, uploaded it to a couple of bbs's and sat back and waited
would get rich.  He said that the shareware approach provides a way to let the
users decide (rather than the people who control the advertising prices) which
programs should succeed, based solely on the quality and usefulness of the
program.  Shareware is not some magic way to get rich from trivial or
substandard, amateurish products of limited appeal or usefulness.

Some shareware programmers who have failed prefer to blame the shareware
approach rather than themselves.  They think that millions of people are using
their programs without paying and that the shareware concept just doesn't work.

To these people we always reply:  If shareware doesn't work, how are Button
(PC-File), Wallace (PC-Write), Smith (Procomm), and Magee (Automenu) all
making over a million dollars a year at it?  "These are exceptions!" they
reply.  Sure they are exceptions.  Anyone making a million dollars a year at
anything is an exception.  Many others are making lesser, but respectable,
incomes.  Not bad for a business that anyone can get into at virtually no
up-front cost.

Yes, shareware definitely works.  Like anything else, how well it works for
you depends on hard work, ability, and even a little bit of luck.  And even
luck often boils down to being prepared to take advantage of opportunities
when they coming knocking.  We hope this guide will help you get prepared.


PROGRAMMER'S GUIDE                                                 Introduction


INTRODUCTION

You wrote a program to fill a particular need that you had or maybe just for
the fun of it. Now you are thinking about selling it, but you are not sure of
how to go about it. Well, what you do next depends on how seriously you want to
pursue the marketing of your program. If you are very serious, you may find out
that your work has just begun, and that the programming was the easy part.


Going All Out:

Some programmers quit their old jobs, hire people to write their manuals, have
the manuals and disk labels professionally printed, send copies of their
program to hundreds of user groups and shareware distributors, get an 800
number and credit card accounts, hire staff to take and fill orders and
provide customer support, go to trade shows such as Comdex, go on speaking
tours to user groups, advertise and publish product newsletters.  They arrange
deals with distributors and dealers in the U.S. and overseas.

Taking a Smaller Step:

Some programmers, not ready to go all out, keep their "day job", but still get
manuals and labels printed, send out copies of their programs to lot of groups
and upload to bbs's. If demand grows, they may hire an answering service to
take orders.  Some just have an answering machine.  Others only take mail
orders and don't publish a phone number at all.

Taking it Easy:

The least successful, or at least slowest to succeed, method is to upload your
program to a few bbs's with a request for payment from satisfied users.  You
don't send out printed manuals, take phone orders, or hire any kind of staff.
This is how Fluegelman first envisioned shareware working.  When it does work,
it works slowly.

Take Vernon Buerg's LIST program, for example.  Buerg originally released it
in 1983, at first asking for nothing, later asking for a voluntary payment of
$15.  He relied completely on word of mouth, not trying to push it at all.  As
LIST slowly gained in popularity beyond the circle of hackers, magazines
started recommending it in articles.  Today, Buerg gets a healthy income from
LIST.  This is indeed a 1 in 10,000 story, however, and it paid off only
because Buerg was willing to continuing supporting users and working on the
program for years before getting substantial payback for it.

Letting Someone Else Do It:

Some programmers have formed partnerships in which the partner handles all the
marketing. That may be a viable alternative if you don't mind splitting the
earnings and have someone whose ability, dedication and integrity you trust.

You might also be able to find an established wholesale or retail distributor
to market your program, rather than using the normal shareware approach.  If
you do, you will probably find that the returns are very low.  If a program is
good, it will sell whether you sell it or a distributor does, but if an
established distributor sells it, you may end up getting 10 cents on the
dollar, or even less, and you may lose the rights to your program.

PROGRAMMER'S GUIDE                                                    Chap. 1

CHAPTER 1:  MARKETING SHAREWARE
-------------------------------

GETTING PUBLICITY

In 1982 and 1983, the relatively few shareware programs available were able to
get exposure in the press simply because of their uniqueness.  In 1984, there
was a column on public domain ("pd") and shareware software in Softalk
magazine, but the magazine folded at the end of 1984.  After that, reviews of
shareware in the computing press were scarce for a couple of years.

The years 1987 and 1988 saw increased coverage of shareware in the press, but
also saw an even larger increase in the total number of shareware programs
available. (At the PSL, we screen over 400 programs a month.)

Sending your programs directly to a magazine will probably do no good. PC
Magazine and its ilk cannot possibly assimilate even a small fraction of those
400 programs a month.  Even the few who get mentioned (in fact, even some who
have been named Editor's Choice in comparative reviews in PC Magazine) report
a short burst of activity that doesn't have that much impact in the long run.
(Look back at 1982-1985 PC Magazines and see how many Editor's Choices are
no longer around.)

Sending press releases to non-computer magazines might get you more attention
because the computer angle is more unique to them and their readers.  For
example, if you have a wonderful video tape cataloging program, send PR's
about it to all the video magazines.

SENDING OUT YOUR PROGRAM

Rather than waste time and money sending your program to magazines where it
will probably be ignored or at best, generate a short-term benefit, spend the
time and money sending your disk to distributors and user groups and uploading
to major BBS's, such as CompuServe.

Make sure your program is stable for a while before doing all this, because
you don't want to have to suffer the expense (and embarrassment) to send them
all out again in a few weeks to fix a bug.  You can often get a lot of good
user feedback by distributing the early versions of your program to just a few
places.  After the feedback has resulted in an improved, bug-free, stable
program, then start sending out to as many places as you can afford.

You can get the names and addresses of user groups and numbers of bbs's from
some magazines such as Computer Shopper.  You can get names of distributors
from ads and articles in magazines, but if you see an ad that pretends to be
actually selling the software and doesn't explain what shareware is, you
should give consideration to whether you want them misrepresenting your
program to the public in that way. Update: The Association of Shareware
Professionals now screens and licenses shareware distributors. Many ASP
members restrict distribution of their programs to ASP approved vendors.

After your first major, widespread release, you should probably aim for a
major update about every six months to a year.  Any more than that and people
will get fed up with having to update their software.  Any less than that, and
some other program may out-feature you and steal your business.

PROGRAMMER'S GUIDE                                                    Chap. 1



ADVERTISING

In general, advertising shareware does not pay for itself in direct sales.
Even the little low-cost classified ads in the backs of magazines generally do
not pay off.  And yes, that even includes ads in PSL NEWS!  Such advertising
is mainly good for increasing long-term public awareness of your product(s).

Shareware programmers also report dismal results with those card decks which
many people throw away without opening.  Marshall Magee (Automenu) says: "I
have done two card decks, PC Softdeck and another one. I don't think it was
worth the money."

The best form of advertising for your program should be the shareware version
of it.  If that won't sell your program, an ad surely won't.  Spend your time
and money getting your shareware disk out to users or to people who will
distribute it to users.

Shareware distributors can afford to advertise because it should generate repeat
business for them that should pay off in the long run. Few shareware authors
expect or get repeat business from the average customer, with the except of
occasional, smaller update fees. Let the distributors advertise your program for
you by listing it in their ads and catalogs. Why should YOU pay for the
advertising?

Again - the best use of your time and money is getting your program out into
people's hands by sending it to distributors and uploading to BBS's.


A "PURE" SHAREWARE MARKETING STRATEGY

Some programmers get so paranoid about stopping people from using their
software without paying for it that they forget that these people are their
distributors too.  By cutting them off, you cut of your lines of distribution.

Here is a "pure" shareware marketing strategy:  Make your goal the first year
to get as many people using your program as possible without worrying about
who is paying and who isn't.  That first year, you should either be working on
polishing the program or on pushing the program all the time.  If you can hit
"critical mass", in terms of number of people really using your program, then
the money should take care of itself. If your program becomes a clear standard
then your leverage in getting people to pay becomes much greater.



PROGRAMMER'S GUIDE                                                    Chap. 1


SHAREWARE VS RETAIL-ONLY SOFTWARE

In general, a program that will not succeed as shareware will not make any
money in the retail-only market either.  In fact, it may lose money.
Conversely, a program that sells well in one market would probably sell well
in the other too.

Games and niche products with a limited user base are difficult to sell in
either market.  Programs that can be used by businesses on a daily basis are
the top money-makers in both markets.

There are some differences, though, from both the user's and the programmer's
points of view.  As a programmer, you need to be aware of these difference so
that you can plan around them.


The User's Point of View:

* TRY-BEFORE-BUYING:  The theoretical advantage of shareware to users is being
able to fully try a program before paying for it.  However, this shareware
advantage is starting to be negated by retailers who allow users to return
retail software within a 30-day trial period.

* RESPONSIVENESS:  Shareware authors are generally more responsive in terms of
making changes.  An author of retail software who wishes to change his program
may have to get back the old version from distributors and have new labels,
brochures and documentation printed.  A shareware author just puts out a new
disk.  On the other hand, authors of retail programs are usually available for
telephone support, if you can get through to them, which may not be the case
with shareware authors who have other jobs during the day.

   A major problem with shareware is that programmers move, but old versions
of their programs continue to circulate with the old address.  If possible,
get a P.O. box and keep it after you move. I still get a couple of Diskcat
registrations a week at a P.O. box that I haven't officially used for nearly
three years. Another solution is to join ASP (discussed later) so that users
can locate you through that organization.

* COSTS:  The argument used to be that shareware could be cheaper than retail
software because you didn't have to pay for printed manuals that sit on the
shelf and fancy packaging that gets thrown away. Ironically, today virtually
all major shareware programs includes those trappings. It's felt that users
have to feel that they are getting something for registering beyond fulfilling
a theoretical legal obligation.

     Another alleged cost saving was eliminating the middle man - the
distributor.  Now many of the top shareware authors are selling through
distributors too.  These old, specious arguments ignored the fact that these
"extra costs" also generated "extra income" that more than offset them for a
successful product.

     In addition, Borland Software led the way in driving down retail software
prices while registration fees for some shareware have increased dramatically.
For example PC-File, which cost $25 in 1983 now costs about $90.  Of course,
at the same time, the functionality of PC-File has increased correspondingly,
but the point remains that shareware is no longer just "cheapware".

PROGRAMMER'S GUIDE                                                    Chap. 1


(Shareware vs. Retail, cont)


* PROGRAM COMPLEXITY: Shareware programmers normally work alone while retail
software companies can employ dozens of programs for large, complex projects.
As a result, some types of shareware programs cannot match all the features of
retail programs of the same type.  For example, a graphics related shareware
program may only support a couple of printers while a similar retail program
may support dozens.


* PROGRAM QUALITY:  Many times, retail products contain serious bugs and there
is little or nothing the user can do about it.  The retail company may NEVER
fix them.  In 1985, we tried to produce a program for sale in the retail
market using IBM's new $500 BASCOM 2.0 compiler which had so many bugs that
our product, which we had finished on time to meet our advertising and other
deadlines, would not run.  IBM made numerous "unofficial" revisions (ie:  we
had to learn about them second hand), but never got all the serious bugs out.
Evidently, they eventually gave up on it.  We lost tens of thousands of
dollars as a result.

     In contrast, if a shareware program has serious bugs, people just don't
pay for it.  In fact, some people probably use the existence of any bugs, no
matter how insignificant, as an excuse not to pay.  Therefore, shareware has
to be in better shape than does retail software to succeed.



The Author's Point of View:

* COSTS:  Advertising is horribly expensive. You can go broke quickly trying
to break in a new program.  The shareware approach offers a low- or no-cost
alternative.  Not only can you get into shareware marketing for virtually
nothing, you can afford to take whatever time is required to establish your
program since maintaining a presence in shareware can cost you nothing.

     Even so, if you want to have printed manuals and labels, to send out
disks to user groups, to join and participate in the ASP, figure on spending
at least a couple of thousand dollars, and be happy if you break even the
first year.


* TIMELINESS:  A single magazine ad may make more potential users aware of
your program in one month than shareware distribution will reach in a year or
more, if ever.  If you have a program that will be worthless a year from now
and no follow-up versions are likely, you are almost certain to make nothing
in shareware, and it will be difficult, at best, even in the retail market.
The shareware authors who are now making over $1 million a year report that
they got very few registrations for the first six months to a year.  In
shareware, patience is not just a virtue, it is essential.

     By the way, while a single ad may make a lot of people aware of your
product, that doesn't mean that you will sell enough to break even on the cost
of the ad. "Being aware" does not directly equal sales.



PROGRAMMER'S GUIDE                                                    Chap. 1


(Shareware vs. Retail, cont)



* COMPETITION:  In 1984, we said that the retail market is more crowded and
the competition fiercer. Now the reverse is true. There are more and more
amateur programmers each year with better and better programming tools.
Skyrocketing advertising costs force most of these people into the shareware
market rather than the retail market.

     While improving on someone else's idea is a time-honored way to make
money, people keep cranking out more and more of the same programs.  When
there are dozens of the same type of program available, it becomes more
difficult for any one programmer to make money.  Do yourself a favor and check
on what is already available befor programming your brains out.  The PSL's "PD
& Shareware Reviews Disks" contains write-ups of thousands of programs, all
arranged by subject matter.  Look there before you leap.


* IMPULSE SALES:  The shareware author gets no money from impulse sales nor a
user's mistake in buying a program that he doesn't need.  Everybody with more
than six pieces of retail software probably has one that he bought and has
never used because his needs changed or he didn't like the program. The author
doesn't care that much if you use the program or not - he has his money.


DO USERS PAY?

Commercial software houses' wildest claims wouldn't put the percent of people
who haven't paid for their programs out of total users at over 50%, yet most
shareware authors estimate that from 80% to 99% of people using their program
have not paid.

Are these estimates valid, or are they just sour grapes from people with bad
programs?  Nobody knows for sure.  Certainly there a lot of people using
software of all kinds, shareware AND retail, without paying for it.  Retail
software houses tried to get these people with copy protection, and it did not
work.  Shareware authors have tried crippling (limiting) their programs, and
it has not worked either.  In both cases, the crooked user is going to find a
way to get his "free" software, so all the programmer has done is create ill
will with the honest users.


Here are traps programmers fall into which only serve to insure their failure:

1. Lack of patience.  Remember that it usually takes six months to a year for
a program to begin to reach a broad enough range of people to begin bringing
in significant returns.  During that time, if you want to succeed and really
believe in your program, you have to keep pushing it and improving it just as
if you were making a million dollars.


PROGRAMMER'S GUIDE                                                    Chap 1


(Do Users Pay?, cont.)



2. Overestimating the program.  Some programs are just not that good.  It is
easier for programmers to believe that ten thousand people are using their
program and not paying for it than to believe that the program just isn't that
good and to continue working to improve it.

   And a sad fact of life is that sometimes outstanding isn't good enough.
Many authors have sent us press clippings saying how great their programs are
and complaining that they have gotten few or no registrations.  They blame
shareware, ignoring the fact that many outstanding retail programs, highly
acclaimed by the press, have also gone under.  Homebase, now a shareware
program owned by Brown Bag, was once a PC Magazine's "Editors Choice" as a
retail-only program originally owned by Amber Software.


3. Overestimating the number of users.  A commonly heard complaint is "200
people downloaded my program from CompuServe and I only got 2 registrations. I
know more people than that are using it."  Many people who download programs
or buy disks from distributors do so out of curiosity or to get programs for
their own bbs's or libraries.  It takes TIME for these people to get your
program out to the masses, and more time for the masses to use the program
enough to want to pay.


4. Trying to sell trivial software.  People are generally not going to pay for
a trivial program, especially since there usually are a lot of free versions
of the same thing around if a program is trivial.


5. Not working at marketing.  It takes a lot of work to get your program out
to people, to get it reviewed by magazines, user groups and shareware
distributors, and to continue to improve it in response to users.  Most people
getting into shareware have no concept of having to market their programs.
Marshall Magee, author of Automenu, has defied the odds by making big bucks
selling a shareware program in a very crowded field - DOS menu programs. He
does it by pushing his product to anyone who will listen.


6. Not continuing to improve. I have heard many programmers say that they were
not going to invest any more time adding features or fixing bugs until they
got some registrations. This brings certain failure. Most people originally
write shareware for their own use or for the fun of programming. For the first
year, your best bet is to not even think about registrations: continue to work
on the program for your own use or enjoyment and don't worry about who might
be using it. Remember, people who work at something just for the money seldom
get pleasure out of what they are doing, and those work at something because
they love the work usually find that the rewards come without worrying about
them.

PROGRAMMER'S GUIDE                                                     Chap 1



When programmers fail because of the preceding points, they usually start
resorting to desperate measure such as the following:


CRIPPLED DEMOS

Crippled demos are what retail software houses sometimes provide potential
customers. By disabling some critical function, such as the ability of a word
processing program to save a file to disk, they allow the user to try out all
the other functions of the program to see if they like it without taking the
risk of sending out the complete program.

You may wonder why shareware authors don't just send out crippled demos
instead of fully functioning programs for which some users don't bother to
send payment.  The theory is that the more copies of your program being used,
the more money you will get in the long run as your program becomes the
standard.  This is what happened with PC-Write and PC-File, both of which have
reportedly made seven-figure earnings for their authors.  But PC-File's Jim
Button estimated in 1985 that fewer than one person in 20 using the program is
paying for it.  (We question the validity of that figure, which is surely
pulled from a hat, but that's beside the point.)

You would have to be an iron man to stoically accept the fact that, no matter
how much money you've received which you might not have otherwise gotten, there
are thousands of people around who are using your program without paying.  So
some shareware authors try the crippling technique.

The most common tactic is to omit parts of the documentation that explain more
advanced program features. When the user makes payment, he gets a printed man-
ual with the missing sections which may not be copied for others. This tactic
will only work for programs with large amounts of documentation and with
advanced features.

Other authors offer less powerful versions of a program as shareware that may
be freely copied and more powerful versions that may not be legally copied.

Remember that while these tactics may ensure a higher ratio of paid users,
they also cut down on the number of total users.  Since you are relying on
word-of-mouth instead of paid advertising, you may get fewer "cheaters" but
you may also actually get fewer paid users.

Another reason that people don't pay may be because of shareware distributors
who mislead the people into thinking they are buying the software when they
pay the distributor's disk fees.


PROGRAMMER'S GUIDE                                                    Chap 1



PD/SHAREWARE DISTRIBUTORS:

In the beginning, the idea of shareware was that users would give copies to
each other and user groups would give free copies to members.  Everything was
done for free.

However, as libraries and user groups grew, librarians started charging fees
to cover their expenses.  Many libraries have over 1,000 disks and many groups
have hundreds of members to make copies for.  Also, today's groups are filled
with novices who must be assisted in learning to use the public domain and
shareware software and the library must be better organized to avoid confusing
or overwhelming these novices.

Ideally, programs in a library must be tested for functionality, bugs and
viruses; they must be organized by topic; and they must be kept up to date.
Gathering the people with the expertise to do all this is costly and time
consuming and has long since been beyond the capacity of user groups to keep
up with.  In addition, a substantial number of people do not have access to
user groups anyway, so the job of distributing shareware has passed more to
the full-time, professional shareware distributors.

Unfortunately, there are distributors who are just looking for a quick buck
and who do little or none of the work normally involved in testing, organizing
and keeping things up to date.  These same quick-buckers usually misrepresent
to the public that they are selling the programs without explaining what
shareware is.  For example, look at some of the shareware ads in PC or other
magazines and see if the nature of shareware is being explained.

The Association of Shareware Professionals has passed Vendor Requirements
whereby distributors can be approved by ASP.  Under these requirements,
vendors would have to explain shareware in their ads that quote a price.

I strongly recommend that you state in your documentation that anyone charging
any kind of fee for providing copies of your program must have your written
authorization unless they are recognized by the ASP.  On the following page is
a form that is used for Diskcat.

The control number on the form lets you track where registrations are coming
from.  This can be very important as you may have dozens or even hundreds of
bbs's, disk distributors or user groups distributing your program and if you
know who is generating the most registrations, you know to whom it is worth
sending updates.


                   DISKCAT DISTRIBUTION LICENSING AGREEMENT

    Anyone wishing to charge people a fee for giving them a copy of Disk-
    cat must have the written authorization of the author, without which,
    the distributor is guilty of copyright violation.    To receive such
    authorization, send this completed application, along with a copy of
    your software library's order form to:   Nelson Ford,  P.O.Box 35705,
    Houston, TX 77235.    Include $7 to cover the cost of processing the
    application and of sending you the latest version of Diskcat.    For
    distributors already recognized by the Association of Shareware Pro-
    fessionals, this application is not necessary.

         Name of Organization: ____________________________________
         Your Name: _______________________________________________
         Address:   _______________________________________________
                    _______________________________________________

         TERMS OF DISTRIBUTION OF DISKCAT:

         1. The fee charged may not exceed $7, including postage,
            mailer and any other charges.

         2. Your library's catalog or listing must state that this
            program is not free, but is copyrighted software that is
            provided to allow the user to evaluate it before paying.

         3. The offering and sale of Diskcat will be stopped at any
            time the author so requests.

         4. Copies must be made from the copy of Diskcat sent to you
            with this agreement. This is required for control purposes.

         5. Problems or complaints will be reported to the author for
            resolution.

         In return for the right to charge a fee for the distribution of
         the program Diskcat, I agree to comply with the above terms of
         distribution.

         Signed,

         ______________________________________    ______________
                  your signature                        date

         __________________________   _________    ______________
                Nelson Ford           control #         date


PROGRAMMER'S GUIDE                                                    Chap 1


OTHER PROTECTIVE MEASURES

Make use of trademark and copyright protection.  Even if you don't actually
register them, the symbols and notices may protect your future rights. Your
copyright notice should look something like this:
          DISKCAT  COPYR. 1983,1984,1988 NELSON FORD ALL RIGHTS RESERVED
The (C) is generally not acceptable (the C must be enclosed in a full circle),
so spell out copyright or abbreviate it COPYR.  If you have revisions spanning
multiple years, list them all.  The complete notice should be on one line.

Patenting Software - Attorney Jon Wallace tells us:
  Re patenting a program - it is possible, but extremely time consuming
  and costly.  The program must be novel and non-obvious (terms of art)
  and cannot merely solve an algorithm or incorporate a law of nature.
  The process can take two years and cost thousands of dollars.  Is it
  worth it?  Well, if Software Arts had patented VisiCalc, Lotus 1-2-3
  would never have made it to market.

Trademarks:  Generally, if you start distributing your program without a (TM)
notice by the name, you lose the trademark protection.  So spend the extra
four keystrokes and put it on.  Marshall Magee advises:
  The trademark office requires that you send them copies of artwork
  currently being used to market your product with the TM indicated next
  to your word or phrase. The patent & trademark office will then issue
  you a paper telling you that your word or phrase is now a Registered
  Trademark and then you have the right to use the circled R in place of TM.
  CompuServe has a service called IQuest that will allow you to scan the
  Trademark Data Base for less than $15.  This is a cheap way to check on
  whether or not someone else has already registered your words. If you
  send in a name that is already registered, you will lose the $175 fee,
  but that is still cheaper than paying a lawyer to do a search.

Warranties:  You should also put a disclaimer of warranty in your
documentation.  Place it at the front of the documentation where the reader
cannot miss it.  The following is a sample disclaimer that you can use:

                      DISCLAIMER OF WARRANTY

THIS SOFTWARE AND MANUAL ARE SOLD "AS IS" AND WITHOUT WARRANTIES AS TO
PERFORMANCE OF MERCHANTABILITY OR ANY OTHER WARRANTIES WHETHER EXPRESSED
OR IMPLIED.  BECAUSE OF THE VARIOUS HARDWARE AND SOFTWARE ENVIRONMENTS
INTO WHICH THIS PROGRAM MAY BE PUT, NO WARRANTY OF FITNESS FOR A PARTICULAR
PURPOSE IS OFFERED.

GOOD DATA PROCESSING PROCEDURE DICTATES THAT ANY PROGRAM BE THOROUGHLY
TESTED WITH NON-CRITICAL DATA BEFORE RELYING ON IT.  THE USER MUST ASSUME
THE ENTIRE RISK OF USING THE PROGRAM.  ANY LIABILITY OF THE SELLER WILL BE
LIMITED EXCLUSIVELY TO PRODUCT REPLACEMENT OR REFUND OF PURCHASE PRICE.

All of the above legal information about copyrights, trademarks and warranties
is based on careful research, but is presented by one with no legal training.
It is presented to give you an idea of the types of protection available to
you.  Talk to a lawyer or get a book on the subject for more detailed, more
accurate and up-to-date information.

PROGRAMMER'S GUIDE                                                    Chap 1



SELLING REGISTERED VERSIONS THROUGH SHAREWARE DISTRIBUTORS:

Several shareware distributors have begun selling "registered versions" of
shareware programs.  Practices for doing so vary widely.  Some may have you
send them packages to sell on consignment, some may buy packages from you just
like a regular dealer, others may sell the program but have you ship it.

The percentage that the distributor gets also varies widely, from less than
10% to as high as 60%.  Before signing with a distributor who will keep 60%,
keep in mind that if you allow such a distributor to sell your program, for
you just to break even, he must generate more than two-and-a-half times more
registrations from people who would not have registered otherwise.  If out of
25 registrations, 10 of those people would have registered with you directly
anyway, you barely break even.  If half of the 25 would have registered with
you anyway, you have lost money to the distributor.

We think more and more distributors will take to selling registered versions
and in general, this will be beneficial to shareware.  Obviously, if a vendor
is offering PC-File for sale for $89, he can hardly mislead the customer into
believing that a $2-$6 disk fee is the cost of "purchasing" the program.

The main drawback is that you must be careful in selecting those you let sell
your program.  If they rip someone off, you may have to pay.  And you may also
have to cope with rip-off artists who claim to be selling your program, but who
give you none of the money.



SELLING REGISTERED VERSIONS THROUGH "RETAIL" DISTRIBUTORS/DEALERS:

Some of the top shareware authors also sell their programs through normal
retail channels.  While there is nothing wrong with this from the shareware
viewpoint, dealers and distributors often complain when they see "the same
program" being listed in a shareware distributor's ad for a few bucks.

Hopefully, in the long run, increased public awareness about the true
nature of shareware and more truth in advertising by shareware distributors
(both of which are major goals of ASP) will stop this from being such a
problem.  In fact, as more shareware distributors begin to sell both retail and
registered shareware products, the distinction between the two may disappear,
other than the advantage to users of being able to try shareware before buying.

PROGRAMMER'S GUIDE                                                    Chap 1

SETTING PRICES:

Costs were discussed a few pages back under "Shareware vs Retail Software",
but now let's look at the problem of setting a price for your program.

Truism #1: If somone doesn't need a program, the fact that you may have
             grossly underpriced it is not going to induce them to register.
Truism #2: Users don't care if you "really need the money" or if you spent
             10,000 hours on the program. They care about THEIR needs and
             the costs and alternatives for filling those needs.

The two keys to pricing a program are the cost of alternatives and the value
to the user.

Check Out the Competition:

To do a sensible job of setting a price for your product, you need to know the
shareware and retail markets for your product.  Find out what other programs
are selling for and compare your program to them in terms of quality and
features.  For retail products, don't look at list prices, look at mail-order
discount ads. That is your main competition.  For shareware products, the
easiest way to compare is to look in the PSL's PD/Shareware Reviews. The
license (or "registration") fees shown there include shipping and handling, in
order to make comparisons valid.  Don't forget to check both the Small
Programs Reviews disk and the Large Program Reviews disks.

If you have written a simple program and you see other programs like it that
are free or $10 or less, that does not bode well for the odds of your getting
rich from your version.  Even if you don't find any competition, if your
program was easy to write and you overprice it, you can bet that others will
write "improved" versions of your program and ask little or nothing for it.

For example, one month we saw a program that was somewhat unique, but was
clearly trivial to program, had a relatively high shareware fee, and on top of
everything else, had very retrictive policies about who could copy it, plus
the program was poorly designed.  In a few hours, we wrote a version that we
think was much better designed and had a much lower shareware fee.

"Alternatives" are not always other programs.  If you had the world's only
program for keeping track of, say, telephone messages, you still could not
charge hundreds of dollars for it because people still have non-computing
alternatives -- writing the messages down on paper.

Value -- and Pricing Flexibility:

For a program to be a huge success, it must have a large target audience, it
must have a value far in excess of its cost, and it must be appear to be
better and/or cheaper than alternatives.  If the use of alternatives is
already deeply engrained in people's habits, then the program must be greatly
superior to alternatives (not just cheaper) to get people to switch and to
learn a new system. In effect, your target audience is made smaller when your
program's niche is already dominated by a highly successful program.

Sometimes a programmer will price a program very low because he thinks that
will get more people to pay for it.  This strategy is fine if it is based on a
comparison of the program to alternatives, but it usually is based soley upon
desperation and/or lack of confidence.

PROGRAMMER'S GUIDE                                                    Chap 1

(Pricing... continued)



This strategy of trying to low-price a program is most often employed with
low-value programs or programs with small target audiences.  It does NOT work.
Large numbers of people are simply not going to pay for low value programs, no
matter what the price.

Likewise, pricing has virtually no effect on the size of your target audience.
If you have a high value program, but a small target audience, you should keep
your price up (still giving consideration to the cost of alternatives) and use
the extra revenues to try to increase the size of your target audience (ie:
get out and PUSH your program) or to to develop other programs.


Charge for Value to the User, Not for Your Time:

If you are fairly new to programming and it took you weeks or months to
perfect your program, keep in mind that an experienced programmer might
duplicate your effort in a day.  Don't price your product based on the number
of hours you spent, but on the value of the program to the user.


Case Studies:

BASIC compilers used to sell for hundreds of dollars.  When Microsoft
introduced QuickBASIC ("QB"), it had a street price of under $60, although its
value ot the customer was clearly very high and it had a large target
audience.  The reason why was competition for Borland Software who was
releasing Turbo BASIC about the same time and at about the same price.

A company named MicroHelp sells add-on's for QB, usually at prices much higher
than QB itself.  Even though the time and money invested in these add-on's is
undoubtedly many times less than in QB, and though the relative value of the
add-on's is probably far less than QB itself, MicroHelp still enjoys very good
success and, in our opinion, would have no more success if it lowered its
prices.

The reason why is because of two key elements: (1) the relative value of the
add-on's compared to QB notwithstanding, the value of the add-on's to the user
is still many times the price of the programs and (2) for most of these
add-on's, there are no alternatives that are significantly cheaper.


Rabinowitz's SWAP Programs:

In the shareware arena, Chip Rabinowitz has cleaned up with some add-on's for
many popular pop-up programs (such as Sidekick) that reduce the DOS RAM used
by these programs to about 9k.  Again, the price of these add-on's is much
higher than the value of and time/money invested in the original programs, but
that fact notwithstanding, the value of the SWAP programs is many times their
price and the alternative (of not using the SWAP programs and continuing to
waste precious DOS RAM) is not an attractive one.




PROGRAMMER'S GUIDE                                                    Chap 2



CHAPTER 2:  MAKING YOUR PROGRAM USER-FRIENDLY
---------------------------------------------

ON-SCREEN HELP

The first thing most people will do when they get your program disk will not be
to print out and study the documentation; it will be to try to run the program.
So your program should have enough on-screen help to allow the user to run the
program at least well enough to get interested in it.

One popular data base program has one place where instead of a self-explanatory
menu, it shows a series of cryptic symbols and letters from which the user is
supposed to select.  Chances are, the occasional user will have to refer to the
manual every time this part of the program is reached. (Since 1984 when this
was written, the data base program has been improved.)

The most desirable alternative is to have the program work in a natural enough
manner and have enough information on the screen to allow the user to operate
the program with no further help. The second best alternative is to have help
screens that can be called up with a keystroke. The third best alternative is
to have a well-written manual.  The worst alternative is to have users calling
you all hours of the day and night or even have them give up on your program.

Supply defaults. If the user has supplied the name of a file to load, make that
name the default when you ask him for a name to save with. While on the subject
of files, if you ask for a filename, be prepared to let the user see the disk
directory. Some programs make the user exit the program and look at the
directory in DOS if he cannot remember the filename.  A nice checkbook program
in the PSL lets you put a vendor's name and address on a check by entering the
vendor's ID#, but it doesn't let you view a list of vendor ID numbers!

Trap errors. Nobody wants to have ten minutes of keyboard input dumped into the
bit bucket because the program kicked out to DOS when it found a disk drive
door open, or some other minor infraction. One very fine shareware program has
scared off potential users because it gives nothing more than error code
numbers for simple things like having a write-protect tab on a disk. In this
case, the author would have been better off not trapping errors. The program
would have aborted, but at at least DOS would have spelled out the error
messages.

RULES FOR BASIC PROGRAMMERS

Here are two cardinal rules for BASIC programmers:

1. Compile your program. There are many, many users who have never run anything
but 1-2-3 or Wordstar. They do not understand the intricacies of getting in and
out of the BASIC interpreter. They expect to be able to run the program by
typing in its name from DOS. Furthermore, your program will run faster. Also,
some PC-compatibles do not come with a BASIC interpreter. On these, the user
cannot run your program at all! (eg: DG/1, Tava)  (Note: this is even more
true now than when this was written in 1984.)

2. Avoid using the INPUT command. It allows the user to wipe out the screen and
provides very little control to the programmer. Instead, use an INKEY$ routine.

Almost all BASIC programmers are now following these rules, but they still bear
repeating. Not a cardinal rule but still a very good idea for BASIC programmers
is to use assembler subroutines for doing screen writes. Users are accustomed
to instantaneous screen writes in professional programs. An alternative is to
use the paging capabilities of the graphics card but then users with monochrome
monitors must still wait.

PROGRAMMER'S GUIDE                                                    Chap 2


MAKE THE PROGRAM AND KEYS WORK NATURALLY

All programmers should allow full-screen editing. This simply means that the
user can move back to a prior prompt with the cursor keys to correct an error.
Thoughtless (or lazy) programmers make the user go all the way through a series
of prompts and then asks if there are any corrections. The best time to correct
an error is as soon as you notice it. That way, you can get your mind off the
error and back on your work.

Similarly, the Esc key should always allow the user to get out of whatever he
has gotten into.  Nobody likes to re-boot his computer just because he
accidentally selected a wrong option and can't get out of it.  I have seen
retail programs that use the Esc key to execute a command. How perverted!

Make the program as flexible as possible. What may seem to you like a natural,
logical key to strike for a particular function may not seem so to the user.
That's why keyboard modification utilities are so popular. For example, to page
up, you could let the user press either Ctrl-P or PgUp or, better yet, select
his own favorite key to use for that function.


LET THE USER CUSTOMIZE

Send your program out with black and white screens but allow the user to change
colors.  Some programmers use colors that are only visible on color monitors.
Remember that some people use amber or green monitors on color graphics cards.
Early versions of Diskcat tested for the presence of the color graphics card
and, upon finding it, started using yellow (brown) for text.  Of course, it did
not show up on amber monitors.

Allow the user to customize the program for his printer. Ideally, you should
have the control codes for most printers in files on disk so that the user just
selects his printer from a menu. An easier (for the programmer) alternative is
to allow the user to enter the control codes for his printer, although figuring
these out from the printer manual often seems to be beyond the capabilities of
novices.

When your program does printouts, allow pauses for each new page for people
not using fanfold paper.  (This is not quite as critical anymore.  Most people
now use fanfold paper on dot matrix printers or use lasers with paper trays.)
End each printout with a formfeed so that those who do use fanfold paper can
chain printouts into a print buffer.

Make sound effects optional. Some heavily modified versions of PC-TALK sound
like a calliope, there are so many warning beeps and tones built in. These are
not appreciated by others when you are working in an open office or late into
the night at home. Again, some PC-compatibles do not support sound (eg: Sanyo).


PUT THINGS BACK WHERE YOU FOUND THEM

One very useful utility in our library uses colors that do not show up on some
monitors. Worse yet, it does not put back your colors when it exits to DOS, so
you have to reboot the system to be able to see the screen again. Some other
programs put you back in DOS with a 40-character display or in the graphics
mode or with your printer set to print Sanskrit.

PROGRAMMER'S GUIDE                                                    Chap 3


Keeping Your Files Together:

If your files will not fill up a disk by themselves, they will probably be put
on disks with other files. Even if you don't expect this to happen, it is still
a good idea to give your files names that will cause them to be grouped togeth-
er when a sorted directory is done and that make it clear which files are in a
set. If you have files named READ.ME or AUTOEXEC.BAT, they probably will not
survive being put on a disk with another program. Give them unique names.

For example, the PC-DIAL files are named PC-DIAL.COM, PC-DIAL.DOC, and
PC-DIAL.PRO. Since the files total only 90k and are likely to be combined on a
disk with other files, these names will keep the files together.  In contrast,
see the names of a set of programs below:

                  Original Names      Alternatives
                  --------------      ------------
                   MDSECRET.COM       HIDE_MD.COM
                   CDSECRET.COM       HIDE_CD.COM
                   RDSECRET.COM       HIDE_RD.COM
                   HIDDEN.DOC         HIDE.DOC

You should also put a lot of thought into the filename of your program if it is
a short utility that will be mixed in with others. For instance, the average
user is never going to make the connection that GREP is a text-search utility.
A name such as FINDTEXT.EXE would have been better.

One nice utility came out with three files: DOWNLOAD.DOC, DL.COM and RESET.COM.
What typically happens is that these are put on a disk with 60 other files.
Someone looks at RESET.COM, can't find any documentation for it, so they delete
it. Same thing happens with DL.COM. The other problem is that someone skims
through a listing of the disk, sees the name DOWNLOAD, and assumes that it has
something to do with communications and ignores it. Doesn't matter, since the
COM files have been deleted anyway. How much easier things would have been if
the files had been named BKUP.DOC, BKUP.COM (this is a routine to backup a hard
disk) and BKUP-SET.COM (sets the archive bit on a file so that it will be
copied.)


Number Each Release:

Believe it or not, some people send out frequent updates to their programs and
never put a date or release number on them. That makes it nearly impossible for
you to control what versions of your program are in distribution and for users
to know if you have released a new version.


CHAPTER 3:  WRITING THE DOCUMENTATION
-------------------------------------

This is just a brief series of tips. The following book has been recommended by
ASP member Morrie Wilson, author of Command Post:

How to Write a Computer Manual; By Jonathan Price; The Benjamin/Cummings
Publishing Comapny; [phone] (USA); [phone] (CA). Price: $35.
ISBN 0-8053-6870-1

PROGRAMMER'S GUIDE                                                    Chap 3


Multiple Documentation Files:

As mentioned earlier, if you have a large documentation file, don't expect the
user to print and read it right away. If there are some key points that the
user will need to know to get through a first trial run, condense them into a
shorter file and have a batch file print it out for novices.

Your terms of distribution and payment should also be in a separate, short file
where software librarians and users can find them. Authors who bury their terms
of distribution and invoice at the back of a 100k documentation file are just
asking to have them ignored. ASP recommends putting vendor info in VENDOR.DOC.

Formatting and Printing The Documentation:

It is amazing how many authors put the documentation file on the disk with all
of their word processor's formatting commands embedded in it. If the user
can't read the documentation, you've already got one strike against you.

Some people use file compression on the documentation file and the user must
run a program to translate the file. Putting the documentation in a format that
cannot easily be read from DOS is not a good idea because it reduces the odds
that the user will thoroughly read the documentation But if you must compress
it, it is even more important to condense the key facts into a shorter file.

Even if the documentation is in straight ASCII, it is helpful if you add a pro-
gram to print it out to the screen or printer. This makes it easier for novices
to get a printout while the file being in ASCII still allows experienced users
to access the documentation in other ways. The program should allow for pausing
after every page to change paper, if the user needs to do so.

Use a spelling checker. We have talked about how a professional-looking program
will generate more revenues, and nothing looks more unprofessional than blatant
misspellings.

Contents of the Documentation File:

Right after your title page, disclaimer of warranty, and table of contents,
there should be a listing of all files that are supposed to be on the disk,
along with a short description of each. If a file has dropped out in the
distribution process, this will alert the user and save him some frustration.
This information should also be included in your condensed documentation file.

After you've recited all the dry facts in your documentation, try giving the
user some illustrative examples. This can make things a lot clearer to the user
and save you the headache of having to clarify things over the phone.

List all the changes made with each version that's released. This lets poten-
tial users see that you are supporting the program by making enhancements and
fixing bugs and allows users to know if you have fixed problems that they had
with an earlier version.

Make sure that when you refer to a file, the file name on the disk has not
changed.

PROGRAMMER'S GUIDE                                                     Chap 4

              The Association of Shareware Professionals ("ASP")

The ASP was formed as an outgrowth of a Shareware Convention held in Houston,
Texas in February 1987.  Although I put together the Shareware Convention with
the express goal of it leading to a programmers association and that dream did
indeed become a reality, the people who deserve the credit for the success of
ASP are the top shareware programmers such as Jim Button (PC-File), Bob
Wallace (PC-Write), Marshall Magee (Automenu) and Tom Smith (Procomm).  These
people could have adopted the attitude that they were already successful
enough without such an organization, but they did not.  They paid their own
way to the Convention even though they were the featured speakers!

Button was elected the ASP's first (and second) Chairman of the Board of
Directors.  Magee became the first President.  Tom Smith served as a director.
And none of these are "honorary" positions; they involve a great deal of time
and effort.

Many others, such as Barry Simon, Bob Tolz, Joan Friedman, and others too
numerous to mention have also done a tremendous amount of work for ASP as
directors, officers, committee members, and just active members, but I suspect
that had the top shareware programmers not taken such an active role, ASP
would not have had much credibility and possibly would not still be around.

ASP also owes thanks to the sysops of IBMNET on CompuServe.  Sysop Conrad
Kageyama was at the Convention and arranged, on the spot, a place on IBMNET
for the shareware authors to meet electronically and continue our plans. We
have been meeting there daily ever since in what must be a record for longest
continuous business meeting.  ASP also has an annual physical meeting at the
Fall Comdex each year, thanks largely to the efforts of Marshall Magee.


Goals of ASP (as extracted from the Bylaws):

    ASP, the Association of Shareware Professionals, was formed in April
    1987 to strengthen the future of shareware (user supported software) as
    an alternative to commercial software.  Its members, all of whom are
    programmers who subscribe to a code of ethics, are committed to the
    concept of shareware as a method of marketing.

    ASP's primary goals are:

    o To inform users about shareware programs and about shareware as a
      method of distributing and marketing software;

    o To encourage broader distribution of shareware through user groups
      and disk dealers who agree to identify and explain the nature of
      shareware;

    o To assist members in marketing their software;

    o To provide a forum through which ASP members may communicate, share
      ideas, and learn from each other; and

    o To foster a high degree of professionalism among shareware authors
      by setting programming, marketing and support standards for ASP
      members to follow.

PROGRAMMER'S GUIDE                                                   Chap. 4



Membership Criteria:

Regular membership is presently limited to authors of non-trivial programs
which meet the ASP's definition of shareware. Implicit in that definition is
that "shareware versions" should not be crippled nor artificially limited in
features nor in number of uses or time-period of usage.  Membership or
associate membership may also be offered by ASP to people who have found other
ways to make significant contributions to shareware.

A membership application form is available on DL9 of the Shareware forum on
CompuServe (GO SHARE).


Vendor Standards:

ASP has established standards for shareware distributors to follow if they want
to be able to advertise that they are recognized by the ASP.  Basically, the
standards require vendors to be up-front about what shareware is and to honor
any copying restrictions of authors whose programs they choose to distribute.


Meetings on IBMNET:

While the formation of ASP and the forumlation of its policies have gone far
more slowly than anyone could have imagined, that is due largely to the fact
that business is done primarily by electronic meetings.  Discussions that might
take an hour in a physical meeting may take days or even weeks in an electronic
exchange.

Also, unlike virtually any other organization in existence, many members get
involved with the policy making of ASP on a daily basis on IBMNET.

In addition to taking care of ASP business on IBMNET, members frequently
exchange ideas, ask each other for advice, and generally share resources on the
forum.

While ASP's member sections on the Shareware Forum are private, ASP has two
public sections, 8 and 9, that are open to the public. Section 8 is for users
who want to ask questions and discuss shareware issues with the programmers and
vendors. Section 9 is for programmers interested in learning more about ASP.



PROGRAMMER'S GUIDE                                                   Chap. 5


CHAPTER 5:  WHERE TO GET SUPPLIES AND SERVICES

NOTE: The information in this chapter is subject to change at any time.
      Check the date on this file. If it is old, this info may no longer
      be valid; get a new copy of this disk from PsL (1-713-524-6394).

Telephone:

AT&T has a low cost 800-line service called the Ready Line which is relatively
inexpensive.  For about 25 cents a minute out of state, about 35 cents a
minute in state (for Texas), you can have a fancy 800 number just like the big
boys.  Most of the good acronyms are already gone, but you should still be
able to come up with something.  At the PSL, our number is 1-800-2424-PSL,
which we think is easy to remember.  However, we were not able to get
anything like 800-PSL-DISK or 800-SHRWARE, which would have been better.

Another shareware distributor had the number 800-IBM-DISK, but IBM clamped
down on them for trademark infringement.

The Ready Line 800 number is assigned to your regular telephone number, so you
do not even have to get a second line, unless you just want to be able to know
for sure if someone has dialed the 800 number.

ASP member John Newlin reports:
    I purchased a product called the Complete Answering Machine ("CAM")
    after reading about it in the July issue of Home Office Computing. It's
    an outstanding system that includes a plug-in card and all the
    necessary software. It runs in the background so the machine it's
    running on is not completely dedicated.  The system allows you to do
    all kinds of nifty telephone things like transferring calls, having the
    caller touch different numbers to get different messages, message
    forwarding, remote message retrieval, etc.

    All messages, greetings, etc, are stored on disk in compressed
    digitized form.  For that reason, a hard disk is almost a necessity.
    The quality of the recording is phenomenal.

    CAM retails for $349, but I got it from 47th Street (800-221-7774) in
    New York for $214 plus shipping.  The name of the manufacturer is
    The Complete PC; 521 Milpitas Drive, Milpitas, CA 95035. 415-434-0145.

Answering Services can be expensive.  If you cannot be available during the
day, your best bet is probably to get a computer voice synthesizing answering
device such as Newlin described.  Many large companies are now using these to
route calls, so there should be less of a small-timer stigma attached to them
as there is to a simple answering machine.


Fax Machines:  All the experts are predicting that everyone will have a fax in
a few years, but it seems a little premature for someone just starting off in
shareware to get one right now.  At PsL, we have been using the Intel
Connection Coprocessor. A FAX card with its own CPU will let you receive and
send messages in the background while you continue to use the computer for
other things.

PROGRAMMER'S GUIDE                                                   Chap. 5

Disk Labels:

PsL sells sheets of laser labels. With font programs, you can make small
quantities of labels at a low cost that look like they were custom printed.
Avery Label Pro is the best laser label program, in my opinion.

The Computer Label Company, 1-800-332-4223 (Ca: 1-800-331-4223) and MEI have
the best prices we can find on standard 3.5" by 1" labels.

PsL's sleeves were printed by Data Envelope (408/374-9720) at an average cost
of about 5 cents each for two-color printing on both sides of tyvek sleeves,
including a one-time charge for plates. This was based on a volume of 50k, but
even in volumes of 1000, you can get two-color sleeves for as little as 10
cents each. The same company printed our labels, which you can get for as
little as one cent each.

Art work - If you can get someone to design a logo you like for as little as
$500, you have gotten a bargain. Don't be surprised to pay $1000 or more. Your
best bet is to find someone who works for a design agency and moonlights.

Blank Disks:

Flip through the pages of Computer Shopper and take your pick.  It makes sense
to us that if you are sending a copy to someone who should make a working copy
from your disk and not use your disk much, the cheapest disk you can find
should suffice, particularly if you are sending out a couple of hundred disks
to distributors.

Be aware that some colored disks (red or orange, in particular) may not be
readable on some disk drives.

Disk Duplication:

In our opinion, disk duplication services are grossly over-priced. However,
others use these services and are happy with them. If you are pushing out
1,000 or more disks a month, you might want to get a duplicator. You can get a
stand-alone, four-disk copier for around $1100 these days, which is a real
bargain; we have paid $2000 for copiers that require a PC. (Call
Micro-Technology Concepts, Inc., 718-456-9100. Tell them Nelson Ford, PsL,
sent you.)

There are many public domain and shareware programs designed to make disk
copying and formatting faster. Before spending even $1100 on a duplicator, try
some of these programs. In the PSL, we have many of them on disk 1-UT-1553,
Disk Copying Utilities.

Diskette Mailers:

A good source of plain, inexpensive, flat diskette mailers for one or two
disks is MailSafe (800-527-0754). Mailers are less than $.14 in quantities of
1000. If you opt for a return address printed on it, it doubles the price, but
looks pretty cheap. Instead, either print your return address labels or try
the next company:

If you want fancy mailers like the ones the PSL uses, try the Ames Safety
Envelope Company, 312-279-9474, 188 Industrial Drive, Suite 431.  Ask for Gary
Traynor.  You do have to order quite a few, however.  For 5,000, the price
should be about $.65 each.  For 10,000, about $.45 each.

PROGRAMMER'S GUIDE                                                   Chap. 5


Boxes:

If you are mailing manuals, you will need boxes. PsL gets boxes from Fidelity
(800-328-3034) and Iroquois (800-453-3355). Call and ask for a catalog. We
also get some boxes from local box stores, although they cost a bit more per
box. The companies mentioned also sell general office supplies cheaply.


MC/Visa Merchant Accounts:

In December 1989, after the bank our credit card merchant account was in
failed, we called many banks across the country that would not consider any
business that is primarily mail-order, despite the fact that PsL has a
five-year, unblemished credit card history and a sound financial position.

Tens of thousands of other small businesses are in the same fix, or even
worse: they may have no credit card history and/or may be working out of their
homes.

After we finally acquired an account with a local bank, we received a call
from Sharon McManus, of State Retail Service, in South Carolina. Our previous
agent had referred our account to SRS, and Sharon was still working on getting
PsL into another bank. (Nobody had informed us of this, unfortunately.) Even
though we explained to her that it was too late, she spent a long time
discussing the MC/Visa Merchant account situation for small businesses. SRS
has an alternative to doing without.

Before considering this, you should try ALL the major banks in your town.
Smaller banks most likely process through the major banks, so you can probably
write the smaller ones off if the major ones have a firm no-mailorder policy.
We found that banks in Chicago, Indiana, and some other areas were more
willing to talk than those in Houston, but they only want to talk to local
businesses.

If no local banks will take you, and you have no credit card history and/or
you work out of your home, Call Sharon at 803-862-1409. Her company is
affiliated with another company named Card Authorization Network. Working
through CAN, which assumes 100% of the liability of your account to protect
the processor, you can get MC/Visa processing capabilities, but at a higher
rate than usual (7.48% on an average ticket of $50, for example).

After six months with CAN, according to Sharon, you would have an established
Merchant Account record that would allow your account to be converted into a
Merchant Account with a regular bank. Also according to Sharon, you would
receive cash for your charge tickets within 72 hours of taking the charge.

You should be aware that a lot of unscrupulous businesses are taking advantage
of merchants who are desperate for MC/Visa Merchant accounts. We have heard
many complaints about some third-party services such as Sharon described. Our
impression, based on our lengthy conversation with Sharon, is that her service
is on the up-and-up. But we have no way of actually vouching for her. You will
need to talk to her and make your own decision.

We were not able to locate a phone number for AmCor, one of the largest
merchant services in the country. Trans-Mark is another large service, but
they do not want to deal with businesses that fall below the multi-million
dollar level. In fact, Trans-Mark was the only company that was downright
snotty with us; most were sympathetic, but still unwilling to talk. Another
large company that we could not reach is BancCard, in Colorado.

About 70% of PsL's business is on MC/Visa/Amex. A credit card account is
obviously very important to a mail-order business. If you are determined
enough, there is still a chance you can get one, even if you are small,
work-at-home business, but you should be ready to commit to following every
lead for however long it takes.

American Express & Discover:

While MC/Visa are the big guns, American Express was willing to give us an
account when we were still operating out of our home. At the time, Discover
was not willing to do the same. However, we have recently (5/9/90) been told
that Discover has recently set up a branch for mail-order businesses. We do
not know at this time if this includes in-the-home businesses.


Printers:

My number one choice for a printer would be a PostScript printer with HP and
Epson emulation. The IBM is a good choice. NEC has gotten mixed reviews. The
PostScript translation software that lets you print PS on most printers are
VERY slow and imperfect in their translations.

If you absolutely cannot afford $2500-$3000 for a PostScript printer, my next
choice would be an HP LaserJet, purchased from a discount house. Other brands
may promise more features, compatibility, etc, but as one who has purchased
two non-HPLJ, our discovery is that clones might not be 100% compatible, and
with the HPLJ discounted to about the same price, why risk it. HPLJ is *the*
standard for non-PostScript laser printers, so anything new to come out for
lasers is sure to work on the HPLJ, maybe not on "compatibles."

If you really cannot afford an HPLJ, my next choice would be the HP DeskJet,
an ink-jet printer with laser printer quality. The only drawback is that the
ink smears if you get it wet. HP is said to have this problem about solved.

If you need to do mailing labels and using laser labels in an HPLJ won't work
for you, resist the urge to get the "industry standard" Epson. We got Epson's
and the fact that the labels can only be fed in from the back causes endless
problems. As the labels curl around the platen, they tend to come off in the
machine, catch on the print head, etc.

The owner of the Computer Label Company advised us to get a bottom-feed
printer, such as an Okidata. We did so and have had no more problems.

PROGRAMMER'S GUIDE                                                   Chap. 5


Manuals:

If you are just starting, consider just having a manual on disk until the
number of registrations is enough to convince you that you could use a
thousand manuals in a year or so. A cheap looking, poorly done manual is worse
than no manual at all.

If you have a small manual (less than 100 pages), you should be able to get
1000 copies for about $1000. Check your local printers, but also check with
Whitehall Press, who did PsL's Source Book. Their number is 312-541-9290.
Many shareware authors have used and recommend them. We checked several
printers for our book, and ended up with Whitehall anyway. For my Diskcat-5
manual several years ago, I just used a local printer to print a first run of
500 copies with a glossy, two-color cover. I also paid an artist about $1200
to do the art and color separations for the cover, the labels and ads.

Don't worry too much about your manual being rendered obsolete by program
updates (short of major rewrites). Even big publishing houses have adopted the
technique of putting the latest info in a READ-ME file on the disk.


Shrink-Wrap Machines:

Almost everyone in the ASP who has a shrink-wrap machine has the AJM machine
and is happy with it, including me. The system consists of a 16" sealer unit,
an industrial 14-amp heat gun, and a 10" by 2000' by 75-G roll of film.


                                  APPENDICES
PROGRAMMER'S GUIDE                                                     App.  A

David M. Berdan, author of File Express, offers the following advice:

Be consistent.  Keep the same style throughout your entire program.  A user
should be able to use the same commands and choices in all parts of a program
for things like returning to previous menus and choosing similar options in
different sections.

Thoroughly test and debug your product. Typically, it takes about 20 - 30
percent of your time to actually write the code fo a program and the remaining
70 - 80 percent to refine, enhance and debug. Nothing is more disconcerting to
the user than to crash out of a program in the middle of something important.

Write thorough, complete, understandable documentation for the product. The
manual should answer almost all the questions the user might have before he
even asks them.  Poor documentation can ruin an other wise excellent product.


Edward H. Kidera, author of PC-KEY-DRAW, writes:

The response has generally been poor, although I do get a lot of phone calls
from unregistered users.  I am just about ready to release a version with many
more features, but I am in a dilemma: how should I release the new version?

In analyzing the situation I have come up with the following break down (in no
particular order) of possible reasons for insufficient interest:
1. Not enough time has elapsed.
2. The price is too high.
3. The price is too low.
4. The program is too hard to use.
5. The documentation is not sufficient.
6. People aren't honest.
7. The shareware approach is flawed in concept.
8. There are superior programs readily available.

To begin with, I firmly believe that the shareware concept is a good one. It
provides tremendous benefits to the user by allowing him to try first and by
providing low-cost software. Secondly, I am convinced that people are honest.
What then is the problem? In preparing the next version, I have held two
convictions: that the program should be easier to use and that the documenta-
tion should be expanded. The impact of these improvements cannot be assessed
until after the release of the new version, so I don't know yet how much this
will help.

Price: $45 may be more than the home user wants to spend while the business
user may think that anything that only costs $45 cannot be as good as something
that costs $450. After all, it probably costs the company $45 just to process
the payment.

So here I sit in a dilemma that I must solve and soon.  Perhaps I don't really
understand the situation at all, but I must make a decision soon. Having put
many long hours into a program, I now want very much to reap some benefit. Is
shareware the way to go, or should I be marketing the program like so many
others with copy protection and a $400 price tag.  Perhaps someone can provide
me with much needed insight.

PROGRAMMER'S GUIDE                                                     App. A



Ed Kidera followed up with another letter:

Over the last couple of weeks I have been investigating further the various
marketing approaches. In doing so I came across several interesting articles.
One of them is the farewell editorial of Compute's PC&PCjr. It points out that
the vast majority of IBM's and compatibles are owned for business and not for
home use. In my previous letter, I suggested that the prices of shareware may
be too low for businesses. Since it would seem that we should be aiming our
efforts at this majority of the market, should prices be higher?

The other articles were discussing software in general.  Shareware needs better
press. Users need to be educated.  They must be shown that they have something
to gain from this approach.  Magazines tend to ignore shareware, probably
because they do not expect any benefit from talking about it.  Perhaps with a
shareware co-op doing advertising, this would change.

The average user is very limited in his use of the computer. He may use it for
nothing but word processing or for spreadsheets. These users represent a big
potential market, if they can be educated. This group needs programs that are
very simple and easy to use.  this again brings up the concept of multiple
versions. Distribute an introductory version as shareware and sell the full
working version at a considerably higher price.


Editor's Note:

Ed Kidera has followed up on his last idea with a file encryption program. His
shareware version will encrypt a letter or similarly small file, and he has a
more powerful version available for a higher price.

[1989 Addendum:]

Evidently, Kidera's encryption program never had any great success, once again
pointing out that success depends more on a good product that a lot of people
need than on gimmicks intended to keep people from getting to try out your
best effort.

By way of analogy, let's say you were going to buy an expensive, fully-loaded
car and wanted to test-drive it first. If the salesman said "I'm sorry, we
don't trust you to test-drive that car, but we have a little stripped-down
compact car that we will trust you with. Try it instead." Would you be
inclined to buy from this dealer?


PROGRAMMER'S GUIDE                                                     App. A


Frank A. Bell, author of NEWKEY, writes [in 1984]:

I am glad to see someone getting the shareware authors together. It would be
great if a shareware authors group could be formed to share experiences and
ideas. I have thought of doing something like that myself, but I am not willing
to give up the time it would require.

I have decided to replace the manual on the disk with a tutorial designed to
demonstrate the major features of Newkey. Users who register will receive
the latest version of Newkey that can be copied for others, plus a printed
manual that may not be copied.

Jim Button told me that when he stopped putting the full manual on the disk he
received a lot of registrations from closet users as well as orders for extra
copies of the manual.  I am also raising the payment to $39, still a great
bargain, considering the manual and greatly enhanced features that will be
available in 2.0.

I was interested in the letter by the author of PC-KEY-DRAW.  Unfortunately, I
no longer have the same faith in people's honesty that I once had.  I have had
several good experiences and some not so good.

[Editor's note:  Both Bell and Button gave up on "short-sheeting" their
documentation and now include their complete documentation on their disk. The
following is a 1988 note from Frank Bell. In it he mentions a "delay screen".
This is a screen at the start of a program which explains the shareware
concept to users and it also serves as a minor annoyance and thus a mild
incentive for a user to register and get a version without the screen.]

[Most ASP members have reported a very positive user response to the "delay"
or "shareware" screen as a method of encouraging registration without
crippling the program or limiting the documentation.  Note that the "delay" is
just until the user presses a key.  Actually forcing the user to have to look
at the screen for 15 or 30 seconds is a sure turn-off.  However, to keep the
user from just blowing by the screen by pressing Enter without looking at it,
many of us have had success with putting a random number somewhere on the
screen and requiring the user to enter the number to continue.]

Over the years, I have tried several different methods to encourage purchasing
and none of them have made any substantial difference. However, I have been
using a delay screen and have received several orders with comments such as
"Ok, ok, I'll register. Send me the version without the delay screen." so I do
feel that I am getting registrations that I would not have received otherwise.
I have never received any negative comments about the delay screen.

The purpose of the delay screen is to make integration of my program into the
daily computer operations annoying, but not so annoying as to discourage
evaluation. I have received many next-day air orders from businesses and
consultants who want to install Newkey into a system and don't want the
shareware screen coming up.  Some of these might have ordered if there were no
delay screen, but probably not all of them.

Since I furnish the full manual and my product requires little support,
removing the evaluation screen is the best practical benefit that I can offer.
This way the user can feel virtuous and still get a practical benefit by
registering.